NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/3389

Text File | 1996-08-05 | 4.8 KB | 111 lines

Path: newshost.lanl.gov!tanmoy
From: [e-mail] (Tanmoy Bhattacharya)
Newsgroups: comp.lang.c
Subject: Re: Please help ?!
Date: 28 Jan 1996 17:07:25 GMT
Organization: Los Alamos National Laboratory
Message-ID: <[e-mail]>
References: <4dm889$[e-mail]> <4drnv1$[e-mail]> <4drq5i$[e-mail]>
    <4e6hse$[e-mail]> <[e-mail]>
    <4eg6h8$[e-mail]>
NNTP-Posting-Host: qcd.lanl.gov
Mime-Version: 1.0
Content-Type: text
In-reply-to: [e-mail]'s message of 28 Jan 1996 15:59:36 GMT

In article <4eg6h8$[e-mail]> [e-mail]
(Phil Tregoning) writes:
<snip>
   >> [...] adding a cast to a pointer of the same
   >> type to the malloc return is the *safest* thing you can do:
   >>
   >>   fred = malloc(n * sizeof(int));
   >>
   >> Oops - fred isn't an "int *" it's a "long *", but the compiler wont
   >> issue any warnings, but in:
   >>
   >>   fred = (int *)malloc(n * sizeof(int));
   >>
   >> the compiler will issue an error.
<snip>
   I've also frequently seen the advice not to cast the return from malloc()
   as it supposedly can hide errors, and have followed this advice. However,
   having read what Ray Dunn wrote I thought I would try it out on my compiler
   (DEC C - with default warnings) to see which cases get picked up.

   Missing out #include <stdlib.h>, and with a cast on malloc() gives a
   warning and information message as follows :

       long_ptr = (int *)malloc(sizeof(int));
       ..................^
   %CC-I-IMPLICITFUNC, In this statement, the identifier "malloc" is implicitly
    declared as a function.

       long_ptr = (int *)malloc(sizeof(int));
       ^
   %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value
    "(int ...)malloc(...)" is "int", which is not compatible with "long".

   I would call that fair warning that something is amiss.

   Including #include <stdlib.h>, and without a cast on malloc() gives no
   messages at all on "long_ptr = malloc(sizeof(int));" because a void pointer
   (returned from malloc()) is being converted to a long pointer, which is
   OK as far as the compiler is concerned.

   Given the results of this, I think a may start casting the return from
   malloc().

This issue keeps coming up in this newsgroup, and as any stylistic
question, will probably never be `finally answered'. On compilers
which warn on undeclared functions, avoiding the cast has little
benefit in this particular case. One must keep in mind, however, that
programming is more a matter of habit: and, often, it is best not to
become too used to facilities one has at hand on a particular day on a
particular platform. The compiler _need not_ warn about an undeclared
function (i.e. such a warning is not mandated by ANSI: no warning is
however ever prohibited). Converting an int to a pointer without a
cast, however, needs a warning. On such compilers, then, avoiding the
cast can often help spot a fatal error.

The point that Ray brings up is also one discussed here quite
often. The first thing is that writing

long_ptr = malloc (sizeof (int));

is inherently more error prone than writing

long_ptr = malloc (sizeof*long_ptr);

This second form is useful to learn as an idiom, and avoids most of
the errors that the explicit cast is trying to flag. More importantly,
a malloc is usually found close to the declaration, or close to its
use: and this kind of mistake (i.e. wrong idea of what the type of a
malloced variable is) usually leads to more diagnosable mistakes later
anyway. As this is a statement of what kinds of codes are more common,
every persons experience is likely to be different.

A related point is that a `cast' is a loophole in type-safety, just as
a `goto' is a loophole in structured programming. Both have their
legitimate uses, and in the hands of an expert programmer, both of
them can integrate into magnificient products of art. A beginner
however is often advised to stay away from a goto, I wish the same
were done for casts. Unfortunately, C does not allow complete
elimination of casts: but avoiding them whenever possible is probably
an important lesson that every beginner needs to have.

For people here who have been programming for long, no such rules
apply. As an ancient religious book from India stated, once you
internalize the reason behind a rule, the rule no longer applies to
you.

Cheers
Tanmoy
--
[e-mail](128.165.23.46) DECNET: BETA::"[e-mail]"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: [phone]   voice: 1 [phone]    [ Home: 1 [phone] ]